home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-iplpdn-para-negotiation-02.txt < prev    next >
Encoding:
Text File  |  1993-09-02  |  13.8 KB  |  499 lines
  1.  
  2.  
  3.  
  4.  
  5. Draft               Parameter Negotiation        August 1993
  6.  
  7.  
  8. INTERNET DRAFT
  9. Expires: February 25, 1994
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.                    Parameter Negotiation
  18.                           for the
  19.                  Multiprotocol Interconnect
  20.  
  21.  
  22. Keith Sklower
  23. Computer Science Department
  24. University of California, Berkeley
  25.  
  26. Clifford Frost
  27. Information Systems & Technology
  28. University of California, Berkeley
  29.  
  30. 1.   Status  of  This  Memo    This  document is an Internet
  31. Draft.  Internet Drafts are working documents of the  Inter-
  32. net  Engineering Task Force (IETF), its Areas, and its Work-
  33. ing Groups.  Note that  other  groups  may  also  distribute
  34. working documents as Internet Drafts.
  35.  
  36. Internet  Drafts  are draft documents valid for a maximum of
  37. six months.  Internet Drafts may be  updated,  replaced,  or
  38. obsoleted  by other documents at any time.  It is not appro-
  39. priate to use Internet Drafts as reference  material  or  to
  40. cite  them  other  than  as a ``working draft'' or ``work in
  41. progress.''
  42.  
  43. Please check the 1id-abstracts.txt listing contained in  the
  44. internet-drafts    Shadow    Directories   on   nic.ddn.mil,
  45. nnsc.nsf.net,    nic.nordu.net,     ftp.nisc.sri.com,     or
  46. munnari.oz.au  to  learn  the current status of any Internet
  47. Draft.
  48.  
  49. 2.  Abstract
  50.  
  51. This document describes mechanisms  for  negotiating  opera-
  52. tional parameters wherever the use of an ISO TR9577 NLPID is
  53. available.[6] For example, it is suitable for  use  in  con-
  54. junction  with RFC 1490 (Multiprotocol Over Frame Relay) and
  55. RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the
  56. Packet  Mode) [1,2], and potentially others.  The mechanisms
  57. described here are intended as optional extensions, intended
  58. to facilitate interoperation in public networks were precon-
  59. figuration may not have been done symmetrically by all  par-
  60. ties who wish to exchange information.
  61.  
  62.  
  63. Sklower & Frost                             [Page 1]
  64.  
  65.  
  66.  
  67. Draft               Parameter Negotiation        August 1993
  68.  
  69.  
  70. 3.  Acknowledgements
  71.  
  72. The  authors wish to thank Brian Lloyd of Lloyd & Associates
  73. and Bill Simpson of Daydreamer, Inc. for  extensive  discus-
  74. sion  of  the  PPP protocol, and this draft draws heavily on
  75. some ideas advanced by Bill in related work.   Brad  Steinke
  76. of  Microcom, and Joel Halpern of Network Systems for useful
  77. suggestions,  and  especially  Chris  Ranch  of  Novell  for
  78. details about the protocol itself.
  79.  
  80. 4.  Conventions
  81.  
  82. The  following language conventions are used in the items of
  83. specification in this document:
  84.  
  85. o    MUST, SHALL or MANDATORY -- the  item  is  an  absolute
  86.      requirement of the specification.
  87.  
  88. o    SHOULD  or  RECOMMENDED -- the item should generally be
  89.      followed for all but exceptional circumstances.
  90.  
  91. o    MAY or OPTIONAL -- the item is truly optional  and  may
  92.      be  followed  or  ignored according to the needs of the
  93.      implementor.
  94.  
  95. 5.  Introduction
  96.  
  97. When parties wish to exchange information over a public data
  98. network,  it may be useful to perform sanity checks, such as
  99. verifying that buffer sizes are sufficient to  receive  data
  100. being  transmitted,  or  that there is agreement as to which
  101. protocols will be routed or bridged.   As  another  example,
  102. there may be circumstance in which the identity of a calling
  103. party may not  be  readily  available;  thus  some  form  of
  104. authentication may be desired.
  105.  
  106. The  Point-to-Point  Protocol (RFC 1331 and 1332) provides a
  107. means of achieving these goals [3,4].  It  is  very  general
  108. and can be adapted to any situation where there is a virtual
  109. point-to-point  connection  between   parties   wishing   to
  110. exchange  information.   Both  RFC's  1490  and 1331 specify
  111. details of framing and encapsulation in  incompatible  ways;
  112. however,  one can accommodate PPP's encapsulation of control
  113. packets by prepending a NLPID without otherwise changing the
  114. description  of  the  packets.   Negotiations  are currently
  115. under way with ANSI for the assignment of  a  NLPID;  it  is
  116. believed that the numeric value CF (hex) will be assigned to
  117. this purpose.
  118.  
  119. Members of the IPLPDN group expressed the desire that param-
  120. eter  negotiation  as  a  whole  be  made optional, and also
  121. wanted to be able to renegotiate parameters at any time dur-
  122. ing the course of an association.
  123.  
  124.  
  125. Sklower & Frost                             [Page 2]
  126.  
  127.  
  128.  
  129. Draft               Parameter Negotiation        August 1993
  130.  
  131.  
  132. 6.  Frame Format
  133.  
  134. 6.1.  Basic Format
  135.  
  136. In  this  document,  we  propose prepending an NPLID to that
  137. portion of PPP control packets that follow link media  head-
  138. ers,  such  as  the  two byte PPP address and control field.
  139. The NLPID value is 0xCF.  A system SHOULD recognize incoming
  140. PPP data packets.  We RECOMMEND that only control or negoti-
  141. ation type PPP packets be transmitted in this fashion, since
  142. RFCs  1490 and 1356 already specify a means of encapsulating
  143. data packets.
  144.  
  145. Since we are proposing using this in conjunction  with  both
  146. RFC1490  and RFC1356, we give an example in each packet for-
  147. mat:
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187. Sklower & Frost                             [Page 3]
  188.  
  189.  
  190.  
  191. Draft               Parameter Negotiation        August 1993
  192.  
  193.  
  194.      Sample Frame Relay PPP LCP packet
  195.          +-----------------------------+
  196.          |    flag (7E hexadecimal)    |
  197.          +-----------------------------+
  198.          |       Q.922 Address         |
  199.          +--                         --+
  200.          |                             |
  201.          +-----------------------------+
  202.          | Control (UI = 0x03)         |
  203.          +-----------------------------+
  204.          | Optional Pad(s)   (0x00)    |
  205.          +-----------------------------+
  206.          | NLPID              0xCF     |
  207.          +-----------------------------+
  208.          | PPP  Protocol (e.g. 0x0c)   |
  209.          +--           .             --+
  210.          | PPP  Protocol (0x21 for LCP)|
  211.          |       (two octets)          |
  212.          +-----------------------------+
  213.          |           Data              |
  214.          |   (e.g   LCP  Code  )       |
  215.          +-----------------------------+
  216.          |   (e.g   LCP  Identifier)   |
  217.          +-----------------------------+
  218.          |   (e.g.  LCP  Option Length)|
  219.          +--           .             --+
  220.          |       (two octets)          |
  221.          +-----------------------------+
  222.          |   (e.g.  LCP  Option)       |
  223.          |             .               |
  224.          |             .               |
  225.          |             .               |
  226.          |             .               |
  227.          +-----------------------------+
  228.          |   Frame Check Sequence      |
  229.          +--           .             --+
  230.          |       (two octets)          |
  231.          +-----------------------------+
  232.          |   flag (7E hexadecimal)     |
  233.          +-----------------------------+
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249. Sklower & Frost                             [Page 4]
  250.  
  251.  
  252.  
  253. Draft               Parameter Negotiation        August 1993
  254.  
  255.  
  256.         Sample X.25 PPP LCP packet
  257.          +-----------------------------+
  258.          |    flag (7E hexadecimal)    |
  259.          +-----------------------------+
  260.          | Address A or B   0x1 or 0x3 |
  261.          +--                         --+
  262.          |       LAPB Control          |
  263.          +-----------------------------+
  264.          |  D,Q bits | SVC# high order |
  265.          +-----------------------------+
  266.          |       SVC low order         |
  267.          +-----------------------------+
  268.          | p(r)   | m_bit | p(s)   | 0 |
  269.          +-----------------------------+
  270.          | NLPID              0xCF     |
  271.          +-----------------------------+
  272.          | PPP  Protocol (e.g. 0x0c)   |
  273.          +--           .             --+
  274.          | PPP  Protocol (0x21 for LCP)|
  275.          |       (two octets)          |
  276.          +-----------------------------+
  277.          |           Data              |
  278.          |   (e.g   LCP  Code  )       |
  279.          +-----------------------------+
  280.          |   (e.g   LCP  Identifier)   |
  281.          +-----------------------------+
  282.          |   (e.g.  LCP  Option Length)|
  283.          +--           .             --+
  284.          |       (two octets)          |
  285.          +-----------------------------+
  286.          |   (e.g.  LCP  Option)       |
  287.          |             .               |
  288.          |             .               |
  289.          |             .               |
  290.          |             .               |
  291.          +-----------------------------+
  292.          |   Frame Check Sequence      |
  293.          +--           .             --+
  294.          |       (two octets)          |
  295.          +-----------------------------+
  296.          |   flag (7E hexadecimal)     |
  297.          +-----------------------------+
  298.  
  299. Since one of the packet formats specified in RFC1356 permits
  300. logically  prepending  the  call user data supplied when the
  301. virtual circuit was established to each  packet  transmitted
  302. over  that  virtual  circuit,  one could transmit PPP packet
  303. unchanged if the single byte NLPID is supplied as  the  call
  304. user data.
  305.  
  306. RFC1356  allows  the  use  of single SVC connections between
  307. systems (termed the null encapsulation) indicated by the use
  308. of  a  single  byte  CUD  with  value 0.  In the elements of
  309.  
  310.  
  311. Sklower & Frost                             [Page 5]
  312.  
  313.  
  314.  
  315. Draft               Parameter Negotiation        August 1993
  316.  
  317.  
  318. proceedure described below, if a  system  initiates  traffic
  319. over  such an SVC and subsequently initiates parameter nego-
  320. tiation with a system that may  not  have  implemented  this
  321. extension,  all traffic becomes blocked until the initiating
  322. system has exhausted its PPP timers, whereas the system will
  323. reject  a  call  request with a single byte CUD with the PPP
  324. value immediately.  Also, PPP encodings for  some  protocols
  325. are  more  compact.   Thus  we RECOMMEND that when there are
  326. sufficient SVCS available, traffic requiring parameter nego-
  327. tiation be sent over a separate SVC.
  328.  
  329. 6.2.  Supported Types
  330.  
  331. The  PPP protocol is a rich language and allows many options
  332. to be negotiated.  An implementation MAY request any  option
  333. specified  by  PPP,  but  MAY decline to support any option.
  334. Because PPP and Frame Relay encapsulations evolved  indepen-
  335. dently,  there  are  duplicate  ways to obtain configuration
  336. information such as the IP address of the other end  of  the
  337. PVC  - by inverse arp, or determine the transmit and receive
  338. buffer sizes - by XID negotiation.   Where  there  are  such
  339. choices,  it is RECOMMENDED that an implementation adhere to
  340. practice specified in the Frame Relay and X.25 RFCs.  Manual
  341. configuration  also implicitly provides information that may
  342. otherwise have been explicitly negotiated.
  343.  
  344. 7.  Elements of Proceedure
  345.  
  346. As noted above, people have expressed the desire not  to  be
  347. required  to  conduct  any  negotiations before transmitting
  348. data packets in a public data network environment.  Thus, an
  349. implementation MAY silently ignore any SNAP encapsulated PPP
  350. packet.  If an implementation responds to  LCP  packets,  it
  351. MUST traverse the LCP state diagram according to RFC1331.
  352.  
  353. If an implementation responds to NCP packets for any partic-
  354. ular protocol, it MUST otherwise obey the rules of  the  RFC
  355. for that corresponding NCP.
  356.  
  357. An  implementation  MUST  NOT accept the address and control
  358. field option.  An implementation  MAY  accept  the  protocol
  359. identifier  compression option; however in the case of frame
  360. relay use, we interpret this to mean that the  NLPID  always
  361. remains  present,  but  the higher order zero valued byte of
  362. the protocol identifier field may be removed.
  363.  
  364. One reason for making negotiations optional is  cost;  there
  365. are  environments  which  charge by the packet and there are
  366. applications such as mail hubs which generally exchange only
  367. a  few  data  packets with a given remote host and then will
  368. not exchange any other packets for relatively  long  periods
  369. of time.
  370.  
  371.  
  372.  
  373. Sklower & Frost                             [Page 6]
  374.  
  375.  
  376.  
  377. Draft               Parameter Negotiation        August 1993
  378.  
  379.  
  380. Another  reason is simplicity of implementation.  For use of
  381. small computers at home, people may wish to be able to  only
  382. support  the  required  packet  framing.  Or, for routers at
  383. campus or business hubs, this could reduce  memory  require-
  384. ments from having to maintain state information for hundreds
  385. of virtual point-to-point connections.
  386.  
  387. Another reason is reduction of latency.
  388.  
  389. 8.  References
  390.  
  391. [1]  Bradley, T., Brown, C., and Malis,  A.,  "Multiprotocol
  392.      Interconnect  over Frame Relay", Network Working Group,
  393.      RFC-1490, January 1992.
  394.  
  395. [2]  Malis, A.,  Robinson,  D.,  Ullman  R.,  "Multiprotocol
  396.      Interconnect on X.25 and ISDN in the Packet Mode", Net-
  397.      work Working Group, RFC-1356, August 1992.
  398.  
  399. [3]  Simpson, W., "The Point-to-Point Protocol (PPP) for the
  400.      Transmission of Multi-protocol Datagrams over Point-to-
  401.      Point Links",  Network  Working  Group,  RFC-1331,  May
  402.      1992.
  403.  
  404. [4]  McGregor, G., "The PPP Internet Protocol Control Proto-
  405.      col (IPCP)" Network Working Group, RFC-1332, May  1992.
  406.  
  407. [5]  Postel, J. and Reynolds, J., "A Standard for the Trans-
  408.      mission of IP Datagrams over IEEE 802  Networks",  ISI,
  409.      RFC-1042, February 1988.
  410.  
  411. [6]  International Organization for Standardization, "Infor-
  412.      mation technology - Telecommunications and Informations
  413.      exchange  between  systems - Protocol identification in
  414.      the network  layer",  Technical  Report  9577,  October
  415.      1990.
  416.  
  417. [7]  Simpson, W. A., "PPP in Frame Relay" and "PPP in X.25",
  418.      Lansing Michigan, 1993, unpublished.
  419.  
  420. 9.  Authors' Addresses
  421.  
  422. Keith Sklower
  423. Computer Science Department
  424. 570 Evans Hall
  425. University of California
  426. Berkeley, CA  94720
  427.  
  428. Phone:  (510) 642-9587
  429. E-mail:  sklower@cs.Berkeley.EDU
  430.  
  431.  
  432.  
  433.  
  434.  
  435. Sklower & Frost                             [Page 7]
  436.  
  437.  
  438.  
  439. Draft               Parameter Negotiation        August 1993
  440.  
  441.  
  442. Clifford Frost
  443. Information Systems & Technology
  444. 275 Evans Hall
  445. University of California
  446. Berkeley, CA  94720
  447.  
  448. Phone:  (510) 642-5360
  449. E-mail:  cliff@cmsa.Berkeley.EDU
  450.  
  451. 10.  Expiration Date of this Draft
  452.  
  453. February 25, 1994
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497. Sklower & Frost                             [Page 8]
  498.  
  499.